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[.'invention concerne un proced£ de programmation d'actions de 
ressources, c'est a dire de fonctionnalites d'appareils, dans un reseau de 
communication domestique, notamment un reseau comportant un bus serie 
IEEE 1394-1995. 

Dans un reseau de communication domestique auquel sont relics 
des appareils audio/video ou 'noeuds', un utilisateur devrait avoir la possibility 
de programmer une action d effectuer par Tun des appareils d partir de 
n'importe quel appareil poss6dant un affichage. A titre d'exemple, il devrait 
etre possible de programmer Tenregistrement d'une Emission par un appareil 
d'enregistrement quelconque, par exemple un magnetoscope, d partir de 
n'importe quel televiseur ou autre moyen de visualisation relie au reseau. 

L'invention a pour objet un proced£ de programmation d'actions de 
ressources dans un reseau d'appareils domestiques caract6rise en ce qu'il 
comporte les Stapes de : 

- Emission d'une demande de programmation d'une action par une 
application vers une ressource principale, 

- reservation de ladite ressource principale auprds de son 
gestionnaire de ressources local, et le cas echeant r 

- reservation par ladite ressource principale de ressources 
impliquees dans Taccomplissement de Taction aupres des gestionnaires des 
ressources lies a ces ressources impliqu6es. 

Selon un mode de realisation particulier, cette demande comporte 
un identificateur de la ressource principale et le cas 6cheant d'autres 
ressources impliquees dans raccomplissement de Taction. 

Selon un mode de realisation particulier, le procede conforme h 
Tinvention comporte T6tape de memorisation par ladite ressource principale 
d'une structure de donnees transmise par Tapplication et caracterisant 
Taction. 

Selon un mode de realisation particulier, le procede comporte en 
outre Tetape de memorisation par le gestionnaire des ressources impliquees 
de donnees relatives aux horaires de Taction a effectuer. 



Selon un mode de realisation particulier, la demande de 
programmation d'une action est formulae aupres d'un module logiciel distinct 
de la ressource principale mais localisee dans le meme appareil que ceile-ci, 
ledit module logiciel ^servant ensuite la ressource principale et le cas 6ch£ant 
les ressources impliquSes. 

D'autres caract£ristiques et avantages de I'invention apparaTtront d 
travers la description de deux exemples de realisation non limitatifs, illustires 
par les figures jointes, parmi lesqueiles : 

- la figure 1 est un schema d'une partie d'un r£seau domestique 
representant le fonctionnement selon le premier exemple de realisation, 

- la figure 2 est un schema d'une partie d'un r£seau domestique 
representant le fonctionnement selon le second exemple de realisation, 

- la figure 3 est un diagramme representant des ^changes de 
donn£es selon le premier exemple de realisation, 

- la figure 4 est un diagramme representant des echanges de 
donnees selon le second exemple de realisation. 

La presente description concerne un reseau domestique base un sur 
bus serie conforme d IEEE 1394-1995, ainsi que sur I 'architecture dite 
architecture 'HAVi', definie dans le document 'The HAVi Architecture - 
Specification of the Home Audio/Video interoperability Architecture' en date 
du 1 1 mai 1998, version 0.8, publiee le 1 5 mai 1998 sur les sites Internet 
des entreprises Sony, Hitachi, Toshiba, Philips et Sharp. On se referera & ces 
documents pour plus de details. 

Deux demandes de brevet deposees au meme nom que la presente 
demande traitent plus en detail de certains aspects de ('architecture du 
reseau. II s'agit de la demande de brevet francais numero 9805110 du 23 
avril 1998 ayant pour titre 'Proced6 de gestion d'objets dans un reseau de 
communication et dispositif de mise en oeuvre', ainsi que d'une demande de 
brevet franpais d£posee le meme jour que la presente demande et intitulee 
'Procede de gestion de priorites d'acces a des ressources dans un rgseau 
domestique et appareil de mise en oeuvre 1 . La premiere demande de brevet 
concerne la mise en oeuvre de registres d'objets ou de ressources dans les 
appareils connects au r£seau, ce registre maintenant £ jour la liste des 
ressources ou modules logiciels disponibles au niveau local dans un appareil, 
tandis que la seconde demande est relative a un gestionnaire des ressources 



qui maintient un 6tat des ressources disponibles localement et participe a la 
resolution de conflits d'accds a - ou de reservation de - ces ressources. 



Pour exgcuter une action, telle qu'un enregistrement d'emission, 
5 une application peut necessiter un accfes a des ressources publiques. On 
entend par ressources publiques dans le present contexte des fonctionnalit6s 
d'appareils autres que Tappareil dans lequel s'ex6cute Tapplication, mais qui 
sont potentiellement accessibles par cette application. Font Sgalement partie 
des ressources publiques les ressources accessibles localement par 
10 ('application. Une application peut elle-meme §tre une ressource. Les registres 
mentionn6s plus haut maintiennent d jour une liste des ressources publiques 
disponibles, et une application peut determiner quelles sont ces ressources en 
langant une requSte au niveau de son registre local, qui peut propager cette 
requete aux autres registres. 
15 L'appellation 'module logicieT ('software module' selon la 

terminologie du document HAVi) d£signe aussi bien des applications, des 
ressources que des services d'un appareil. 
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La mise en oeuvre d'une action preprogrammee implique : 

- une ressource principale appel£e 'ressource cible' ou simplement 

'cible', 

- le cas 6ch6ant, une ou plusieurs autres ressources publiques, 
appel£es 'ressources impliquees', egalement necessaires pour mettre en 

25 ceuvre Taction preprogrammee. 

Dans le cadre d'une demande d'enregistrement, la cible est par 
exemple la fonctionnalite d'enregistrement d'un appareil d'enregistrement 
digital (magnetoscope digital, DVD, ...), tandis qu'une ressource impliquee est 

30 un tuner. D'autres ressources peuvent etre necessaires : par exemple un 
transcodeur, necessaire pour traduire le format des donn6es en celui de 
I'appareil d'enregistrement, un service de controle d'acces, pour autoriser 
l'acc£s a des programmes securises, ... 

On tiendra compte de la necessite pour le procede de mise en 

35 oeuvre de Taction preprogrammee de fonctionner normalement m§me si le 
dispositif d'affichage par Tintermediaire duquel Taction a et6 programmee a 
ete rendu inactif (par exemple, Tutilisateur a 6teint le telSviseur lui ayant servi 
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pour la programmation d'un magnetoscope). On se place dans Thypothese 
que ce dispositif ne comporte pas la ressource cible, ni les ressources 
impliquees. 

Remarques pour ce paragraphe: les deux parties (cause et effet) ont 
<St6 inverses. C'est le fait que la ressource principale appartienne aux 
ressources impliquees, et pas au dispositif d'affichage, qui assure la 
robustesse de la programmation. En effet, aprfes la programmation d'une 
action, I'utilisateur peut naturellement eteindre sa tei6. Par contre, il y a peu 
de chances pour qu'SO debranche volqntairement un des appareils impliqu6s (il 
ne va pas enlev®tr son magnetoscope du reseau si il vient juste de 
programmer un enirogistrement). 

La cible accepte ou non Taction demand6e par Tapplication. Au 
moment de la programmation de cette action, la cible doit identifier les 
ressources n<§cessaires pour Taccomplissement de Taction et les r<§server 
pour la periode d© temps voulue. Au moment meme de Tex6cution de 
Taction, la cible et les ressources impliquees doivent se synchroniser. Ceci a 
pour consequence qy® des informations relatives d Taction pr£programm£e 
doivent etre rn<§m©iros<£es dans le reseau. Selon un premier exemple de 
realisation, c'est I© coble qui memorise ces informations et execute Taction, 
tandis que selon un second mode de realisation, c'est un autre module qui 
sera charge de ces fonctions. 

Une action pr6programmee peut etre definie par un certain nomfore 
d'informations, collectees dans une structure de donnees particuliere remplie 
par Tapplication programmant Taction et memorisee selon Texemple de 
realisation soit par la ressource cible, soit par le module autre que la 
ressource cible qui gerera Taction. 

- Le type de Taction 

- Des paramdtres relatifs £ Taction 

- Une date 

- Une heure de debut 

- Une heure de fin 

- La periodicite de Taction 

- Un identificateur de la ressource cible 

- Les identificateurs des ressources impliquees 
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- Des donn6es utilisateur 

Le type de Taction depend de la nature de la cible. A titre 
d'exemple Taction peut etre 'ENREGISTRER' ou 'LECTURE' pour une 
ressource ayant une fonctionnalit6 de m^moire de masse, ou 
'SELECTIONNER_SERVICE' pour un dSmultiplexeur de t6l6vision nurn6rique. 

Les paramfetres, optionnels, servent a d^finir Taction de manidre 
plus sp6cifique. Un paramfetre peut etre un 6v6nement ou un service au sens 
de la norme de diffusion de vid6o numSrique DVB (pour 'Digital Video 
Broadcast'). Dans ce cas, les paramfctres comporteront un identificateur du 
type de param&tre, suivi de la valeur du paramfetre. 

Certains appareils du reseau peuvent ne pas comporter des moyens 
de traitement pour fournir un service de ce niveau. Par exemple, un appareil 
d'enregistrement peut ne pas accepter de paramdtres apr6s une commande 
'ENREGISTRER', car ne pouvant lui-meme controler un tuner, tandis qu'un 
appareil plus complexe, ayant cette possibility, pourra accepter une 
commande de type 'ENREGISTRER service X'. 

La date, les heures de d6buLet de fin et la pgriodicite de Taction 
sont des informations classiques. 

L' identificateur de la ressource cible est n6cessaire pour qu'une 
application puisse modifier une action deja programmee. Ce champ n'est pas 
necessaire si la cible memorise directement Taction pr6programm£e (i.e. si 
cette ressource est elle-meme la ressource principale d'une action 
programmee). 

Si par exemple une application veut connaTtre quelle action 
programmee est associee & une ressource donnee, elle va demander § cette 
ressource les identifiants des ressources principales de chacune des actions 
programm6es dans lesquelles cette ressource est impliquee. L'application va 
alors pouvoir consulter la structure de donn6es de Taction programmee 
qu'elle a choisie, puis va pouvoir la modifier (cette application peut etre par 
exemple celle d'une interface utilisateur, 6ventuellement commands par un 
utilisateur autre que celui qui a programme Taction qui va etre modifiee). 

Les identificateurs des ressources impliquees sont utilises selon le 
mode de realisation, soit par la cible, soit par le module qui comporte la 
ressource requise. La liste permet soit a la cible, soit au module logiciel de 
demander des informations relatives aux ressources impliquees, par exemple 
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par Tintermediaire des registres, ou en leur transmettant directement des 
messages. 

Les donn£es utiiisateur comportent par exemple en texte clair la 
raison d'etre de I 'action, ce qui peut etre important en cas de conflit avec 
une action programme ant6rieurement. Dans ce cas, lorsque le conflit doit 
etre resolu par un utiiisateur, typiquement celui programmant Taction plus 
r£cente, ces donn£es peuvent lui donner des indications sur I'importance de 
Taction. 

Les ressources impliqu£es contact6es soit par la ressource cible, 
soit par le module logiciel responsable de la gestion de Taction devront elles 
aussi m£moriser une partie du contenu de la structure de donn6es ci-dessus : 
les informations relatives d I 'heure et, 6ventuellement, le type d'action, les 
paramfctres, et lies donn<§es utiiisateur. 

Dans le cas ou les ressources impliqu£es savent g£rer les actions 
programmes de fa$on autonome (voir figure 3), elles mSmorisent toutes les 
informations relatives k Taction programmes. Dans le cas ou les ressources 
irnpliqu£es sont pauvres (voir figure 4, presence d'un module logiciel 
responsable de la gestion de Taction), c'est ce module logiciel qui stocke 
toutes ces donnees: il memorise done que la ressource X doit faire une action 
Y £ une heure Z, et ce pour chacune des ressources impliquees qui sont 
locales & son noeud (puisque dans un noeud peuvent exister plusieurs 
ressources, geree par un seul module logiciel par noeud). 

Le premier exemple de realisation est illustre par la figure 1 . La 
partie du reseau representee par cette figure comporte cinq appareils. 
L'appareil 1 est un televiseur, localise dans une cuisine et comportant une 
application 2 (par exemple une interface utiiisateur permettant la 
programmation de Tensemble des appareils du reseau). L'appareil 3 est 
egalement un t6l6viseur, situe cette fois dans la chambre d coucher et muni 
d'une application 4, similaire a Tapplication 2. L'appareil 5 est un d£codeur 
de television satellite numerique comportant une ressource tuner 6 et un 
gestionnaire de ressources 7, tandis que l'appareil 8 est un dispositif 
d'enregistrement numerique de type DVD, comportant a ce titre la ressource 
d'enregistrement 9 et un gestionnaire de ressources 10. En dernier lieu, 
l'appareil 1 1 est par exemple un autre decodeur, qui possede une 
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fonctionnalite de transcodage des donnees audio/video codees selon un 
premier format (celui du decodeur 5) en un second format (celui de I'appareil 
d'enregistrement 8). L'appareil 11 possede par consequent une ressource 
transcodage 12 et un gestionnaire de ressources 13. Les divers appareils, qui 
peuvent comporter d'autres modules logiciels que ceux illustres, sont relies 
par un bus serie 14, par exemple un bus IEEE 1394-1995. 

Selon ce premier exemple de realisation, la ressource cible, dans le 
present cas la fonction enregistrement de I'appareil 8, integre elle-meme une 
application capable de ge>er Taction d'enregistrement. 

On suppose qu'un utilisateur souhaite enregistrer une emission sur 
un service X, a 20h30, le 12 decembre 1999, pour une duree de deux 
heures. Bien que dans I'exemple de la figure 1, une seule ressource de type 
tuner et une seule ressource de type transcodage existent dans le redeau, 
I'utilisateur pourrait, dans un reseau ou plusieurs ressources de meme type 
coexisteraient. choisir entre plusieurs ressources de meme type du reseau 
celle qu'il pr^fererait pour participer a Texecution de I 'action. 

Quand la ressource cible 9 recoit Taction programmed de la part de 
I'application 2, elle effectue une auto-reservation aupres du gestionnaire de 
ressources local 10, en procedant de la maniere decrite dans la seconde 
demande de brevet mentionnee au debut de cette description. Elle effectue 
d'autre part la reservation des ressources impliquees (tuner 6, transcodeur 
12) aupres des gestionnaires des ressources distants (gestionnaires 7, 
respectivement 13). Chaque gestionnaire des ressources memorise les 
donnees relatives a la reservation des ressources qui lui sont associees (c'est 
a dire des ressources ayant la meme plate-forme d'execution que ce 
gestionnaire des ressources). 

Une fois les reservations effectuees, la cible transmet un message 
de confirmation a I'application 2 a I'origine de Taction. 

En cas de conflit de reservation, par exemple en cas de preemption 
ou negociation d'une ressource deja reserved pour une action donnee par une 
application programmant une autre action, le gestionnaire des ressources 
avertit la cible ayant programme la premiere action par un message approprie\ 
Chaque gestionnaire de ressources memorise en effet dans ce but 
Tidentificateur ou Tadresse du module logiciel qui a effectu6 une reservation. 
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A ce stade, en cas de debranchement de I'appareil 1, Taction 
pr^programmee s'executera neanmoins, car toutes les informations relatives a 
Taction sont stock6es au niveau de la cible. 

5 Un utilisateur peut modifier ou supprimer Taction pr6programm6e i 

partir d'une autre application, telle que Tapplication 4. Si Tapplication 4 veut 
accSder d toutes les actions programmees concernant une ressource donnee 
(trouvie par Tinterm^diaire du registre local de Tapplication), Da ressource 
contacts par Tapplication peut donner les identifiants des ressources 

10 principales de chacune des actions programmees dans lesquelles elle est 
impliqu<§e. La totality de la structure de donnee d6crivant Taction programm<§e 
peut etre ensuite retrouvSe en contactant directement chaque ressource 
principals. 

15 Au moment du debut de Taction, la cible relie les difterentes 

ressources grace au module logiciel local appel6 gestionnaire connexions 
('SM' ou 'Stream Manager' selon la terminologie du document HAVi). 

Une ressource peut etre designee sous les termes de gestionnaire 
20 de composante fonctionnelle ('FCM' ou 'Function Component Manager' selon 
la terminologie HAVi). (.'architecture peut alors etre representee par le 
schema de la figure 3, ou une application transmet une programmation 
d'action d Tinterface de programmation d'application faisant partie de la cible. 

25 Le second exemple de realisation est illustre par la figure 2. On 

suppose ici que des ressources n'intdgrent pas duplications capables de 
g£rer les actions preprogrammees, c'est a dire qu'elles ne comportent pas 
d'interface de programmation d'application {'APT selon la terminologie du 
document HAVi) acceptant la structure de donnees decrite plus haut. On 

30 parlera dans ce cas de 'ressources passives'- Passif veut dire dans le 
contexte present que la ressource n'a pas la caracteristique d'agenda (i.e. 
aucune capacite h mSmoriser quelle action doit etre Ianc6e a une heure 
donnee). 

L'application initiatrice 1 5 de la programmation de Taction est 
35 toujours une interface localisSe dans un t6leviseur 16. L'appareil 
d'enregistrement 17 comporte la ressource d'enregistrement numerique 18, 
une autre ressource 19, ainsi qu'un gestionnaire des ressources 20. 



L'appareil 5 est identique a celui de la figure 1. 

Selon le present exemple de realisation, l'appareil 17 comporte 
egalement un gestionnaire d'actions preprogrammees 21. Ce gestionnaire 
d'actions 21 est un service au sens du document HAVi et effectue toutes les 
reservations n6cessaires S I'accomplissement de Taction. Le gestionnaire 
d'actions 21 gere les ressources passives de l'appareil 17, mais aussi de 
l'appareil 5. 

La figure 4 est un schema simplify du principe du second exemple 
de realisation. Pour programmer une action, une application s'adresse au 
gestionnaire d'actions pr6programm6es, qui est obligatoirement present dans 
l'appareil comportant la ressource cible. L'application agit d travers I'interface 
de programmation du gestionnaire d'actions, qui d son tour agit d travers 
I'interface de programmation de la cible. L'appareil comportant le gestionnaire 
et la cible est soit un appareil d fonctionnalites completes (TAV), soit un 
appareil d fonctionnalites intermediates CIAV'). 
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RevendicatBons 

1 . Precede de programmation d'actions de ressources dans un 
reseau d'appareils domestiques caract6ris6 en ce qu'il comporte les Stapes 
de : 

. emission d'une demande de programmation d'une action par une 
application vers une ressource principale, 

- reservation de ladite ressource principale auprds de son 
gestionnaire de ressources local, et le cas £cheant, 

- reservation par ladite ressource principale de ressources 
impliquees dans I'accomplissement de Taction aupres des gestionnaires des 
ressources \\6s S ces ressources impliquees. 

2. Proc6d<§ selon la revendication 1, caracteris<§ en ce que cette 
demande comporte un identificateur de la ressource principale et te cas 
6ch6ant d'autres ressources impliquees dans I'accomplissement de Taction. 

3. Proc£de selon Tune des revendications 1 ou 2, caract6rise en ce 
qu'il comporte Tetape de memorisation par ladite ressource principale d'une 
structure de donnees transmise par ('application et caracterisant Taction. 

4. Procede selon Tune des revendications 1 3 3, caracteris6 en ce 
qu'il comporte en outre Tetape de memorisation par le gestionnaire des 
ressources impliquees de donn6es relatives aux horaires de Taction & 
effectuer. 

5. Proc6d6 selon Tune des revendication prgcedentes, caract6rise 
en ce que la demande de programmation d'une action est formulae aupres 
d'un module logiciel distinct de la ressource principale mais localisee dans le 
meme appareil que celle-ci, ledit module logiciel reservant ensuite la ressource 
principale et le cas echSant les ressources impliquees. 
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